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USING PROGRAM CALL GRAPHS TO 
DETERMINE THE MAXIMUM FIXED POINT 

SOLUTION OE INTERPRO CEDURAL 
BIDIRECTIONAL DATA FLOW PROBLEMS 

IN A COMPILER 5 

FIELD OF THE INVENTION 

The present invention relates generally to a system and 
method of efficiently handling compiler optimization prob- 10 
leras, and more particularly to a system and method for 
solving interprocedural bidirectional data flow problems. 

BACKGROUND OF THE INVENTION 

Optimizing and parallelizing compilers perform data flow 
analysis to insure the correctness of their program transfor- 
mations. Software development environments also utilize 
data flow analysis. The input to data flow analysis is a data 
flow framework as described in Marlowe, T. J., Data Flow 20 
Analysis and Incremental Iteration, Rutgers University 
(October 1989). The data flow framework includes a flow 
graph and a formal basis for describing the behavior and 
interaction of flow graph nodes (HG. 1). The behavior of 
each node is formalized by its transfer function (FIG. 2), 25 
which describes how a node affects the solution as a function 
of the behavior of other nodes. When considered as a whole, 
the node transfer functions present a set of simultaneous 
equations, whose maximum fixed point (MFP) global evalu- 
ation provides the best computable solution at all edges or 30 
nodes of the flow graph. In other words, all other correct 
solutions are either uncomputable or not as precise. 

A data flow framework D is defined in terms of three 
components. That is, D=<FG,L,F>, where a flow graph 
FG=(V,Ej) is a finite set 17 of nodes that includes a 35 
distinguished start node r (shown as node VI in FIG. 1), and 
a finite set E of edges (shown as el, e2, e3, and e4 in FIG. 
1). An edge is an ordered pair (v,w) of nodes; v is the source 
of the edge and w its target. For example, in FIG. 1, VI, V2, 
V3, and V4 are nodes with VI being the start node r. The set 40 
of edges, E, comprise el, e2, e3, and c4. The source of e2 
is 172 and its target is V3. The edges are designated by their 
respective ordered pair of source and target nodes, i.e., (v,w), 
therefore, el=(Vl, V2); e2<V2, V3); e3=(V2, V4); and 
e4=(V4, V2). Where the edge (v,w) is in E, we say that v is 45 
a predecessor of w and w a successor of v. For example, in 
FIG. 1, V2 is a predecessor of V3 and of V4, and also a 

successor of 174. A sequence of edges (v^VjXCvj.Vj) 

(v„.i,v n ) in FG is a path from \ l to v n . For example, in FIG. 
1, el, e2 is a path from VI to V3 and e3, e4, e2 is a path from 50 
V2 to V3. If there is a path from v, to v,, we say that v, 
reaches v y or that v, is reachable from v,. Every node in FG 
is reachable from r, and r is not the target node of any edge 
in E. A cycle is a path for which Vj=v n . For example, in FIG. 
1, the path e3,e4 forms a cycle. A '"meet semilattice" is a set 55 
of elements and a partial ordering of those elements which 
is defined by a "meef ' (n) operator. More specifically, the 
meet semilattice L=<A t TOP30TTOM,<, n>, where A is a 
set whose elements form the domain of the data flow 
problem (i.e., the inputs and outputs associated with the flow 60 
graph nodes), TOP and BOTTOM are distinguished ele- 
ments of A (symbolizing the best and the worst possible 
solution to the optimization problem, respectively,) <is a 
reflexive partial order, and n is the associative and commu- 
tative "meet" operator, such that for any a,b in A, 65 

a<bo=xmb=a 



afw=a 
anixa 
ar\TOP=a 

anBOTTOM=B07TOM 

Where the elements of the domain are sets, examples of 
meet operators are intersection and union. Where the opera- 
tor is union, TOP would typically be the empty set and 
BOTTOM the universal set Where the operator is intersec- 
tion, TOP would typically be the universal set and BOT- 
TOM the empty set Intuitively, higher points in the lattice 
correspond to higher degrees of information. 

The input and output to a node Y are elements of A. A 
transfer function (FIG. 2) operates on the input to a node Y 
to deterrnine the output of the node Y. More specifically, F 
is a set of transfer functions such that F is a subset of 
{f : A->A}. That is, any function in F has A as its domain and 
its range. This set includes the identity function i (which, 
applied to the input of a node, produces output identical to 
the input), and the set is closed under composition and meet 
The data flow effect of node Y is described by its transfer 
function f y in F. The local properties of Y are captured by its 
transfer function: OUTy=fy(In y ), where TN Y and OUT y are 
in A. After a framework has been globally evaluated, each 
node Y has a solution OUT y that is consistent with transfer 
functions at every node. In general, the best computable 1 
solution for a data flow framework is the maximum fixed 
convergence of the equations: 

OUT-TOP 

INy=r\(yX in Prcds{Y))OUT x 

where Preds(Y) is the set of predecessors of node Y. The 
solution to the above equations is called the Maximum Fixed 
Point (MFP) solution. During an evaluation, iterations over 
the flow graph nodes take place until all node outputs remain 
unchanged. During such evaluation, IN y travels down the 
lattice from TOP to the clement that represents the best 
computable solution prior to Y, regardless of the flow path 
taken. 

In a forward data flow problem, for each node Y, IN K is 
defined in terms of the predecessors of Y (as in the equations 
above). In a backward data flow problem, for each node Y, 
IN K is defined in terms of the successors of Y. A data flow 
problem which is either forward or backward is unidirec- 
tional, A data flow problem for which IN y for each node Y 
depends on both the predecessors and successors of Y is 
bidirectional. 

The prior art describes a program in terms of a general 
program model that is also used by this disclosure. This 
program model consists of a set of one or more external 
procedures, where an external procedure is one that is not 
contained (declared) within another procedure but may 
contain internal procedures nested within it. One of the 
external procedures is the main procedure. Recursion is 
allowed: A procedure may directly or indirectly invoke 
itself. 

The containment relationships among the procedures in a 
program P may be represented as a forest of trees F^, where 
the nodes of the trees represent procedures/routines. For 
each external procedure/routine, there is a tree in F^ whose 
root node represents the external procedure/routine. The 
variables declared directly within a procedure/routine are 
local to the procedure/routine, while the variables declared 
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in the ancestors of a procedure/routine in F,, are global to it 
The set of variables global to procedure P is denoted 
GLOBAL(P). Among the local variables of a procedure P 
are zero or more formal parameters. The set of such vari- 
ables in P is denoted FORMAL(P). A variable that is either 5 
local or global with respect to a procedure P is known to P. 
An external variable is one that is global to all the proce- 
dures of a program. The local variables of a procedure are 
visible to it; its global variables that are not hidden from it 
are also visible. The specific mechanism for hiding is 
irrelevant to our method. One mechanism provided for 
hiding a global variable is the declaration of a local variable 
of the same name in an internal procedure. 

The prior art includes a model for procedural interaction I5 
which is also used in this disclosure. In the model, a 
statement in a program that invokes a procedure is referred 
to as a call site. It designates a called procedure, which must 
be visible to the procedure containing the call site (the 
calling procedure). For each formal parameter of the called 20 
procedure, the call site must designate an argument that is 
associated with it. An argument may be a reference argu- 
ment, which is a variable that is visible to the calling 
procedure and is passed-by-reference to its corresponding 
formal parameter. When the call site is invoked, a formal 25 
parameter that is associated with a reference argument 
assumes the same address in memory as the argument. 
Procedures interact at call sites through reference arguments 
and also through variables that are global to the called 
procedure. Thus a call site s is said to pass a variable X to 30 
a variable Y if and only if variable Y is the same variable as 
X and is global to the called procedure, or X is passed-by- 
reference to Y. 

See FIG. 3. The interprocedural structure of a program 
350 is represented by a Program Call Graph (PCG) 300, a 35 
flow graph for which each procedure is uniquely represented 
by a single node (301-304) and each call site by a unique 
edge (311-314). The start node 304 represents the main 
procedure. The node representing a given procedure/routine 
P shall be referred to as node P. The edge (P,Q) represents a 40 
call site in P that invokes Q. By the definition of a flow 
graph, it is assumed that every node in the call graph is 
reachable from the main procedure 304. 

In the presence of procedure calls, data flow analysis must 
make worst case assumptions about the data flow effect of 45 
the call unless the analysis is interprocedural — i.e., is 
performed across procedure boundaries. Worst-case 
assumptions about interprocedural information inhibit pro- 
gram transformations for optimization or parallelization. 
Interprocedural data flow analysis algorithms have been 50 
developed for various interprocedural problems (Banning, 
J., Sixth Annual ACM Symposium on Principles of Program- 
ming Languages, 29-41 (January 1979); Cooper et al., 
SIGPLAN '88 Conference on Programming Language 
Design and Implementation.51-66 (June 1988). 55 

Interprocedural data flow analysis may be either flow- 
sensitive or flow-insensitive. A flow-sensitive analysis 
makes use of the intraprocedural control flow information 
associated with individual procedures. A flow-insensitive 
analysis makes no use of intraprocedural control flow infor- 60 
mation. In ignoring control flow information, such an analy- 
sis does not have to consider the possible paths through a 
procedure, reducing the cost of the analysis in both space 
and time. In general, a flow-sensitive algorithm is more 
precise (i.e., higher in the semilattice) but less efficient in 65 
time and space than a flow-insensitive algorithm for the 
same problem. 



STATEMENT OF PROBLEMS WITH THE 
PRIOR ART 



Particular algorithms have been developed for particular 
interprocedural bidirectional data flow problems, but no 
general method for solving problems in this class has been 
developed. Some interprocedural bidirectional algorithms 
have been based on the program summary graph, a repre- 
sentation developed by Callahan for flow-sensitive interpro- 
cedural data flow problems. Callahan defines the program 
summary graph in Callahan, D., Proceedings of the SIG- 
PLAN '88 Conference on Programming Language Design 
and Implementation, 47-56 (June 1988), where it is used as 
a basis for solving unidirectional flow-sensitive interproce- 
dural data flow problems, KILL and LIVE. The exact form 
of the program summary graph depends upon the problem 
which it is used to solve, but the representation of interpro- 
cedural control flow information is always the same. The 
interprocedural control flow graph (Landi and Ryder, Eigh- 
teenth Annual ACM Symposium on Principles of Program- 
ming Languages, 93-103 (January 1991)) captures this 
common interprocedural control flow representation. Within 
a procedure control flow graph, call site nodes are split into 
call and return nodes. Each procedure control flow graph 
contains an entry node and an exit node. Two interproce- 
dural control edges are added for each call site: one from the 
call node to the entry node of the invoked procedure, and one 
from the exit node of the invoked procedure to the return 
node of the call site. Procedure flow graphs (usually in a 
condensed form) are always used to represent control flow 
within individual procedures. The procedure control flow 
graphs are linked together by interprocedural control edges 
to form the interprocedural control flow graph. In the 
program summary graph, additional edges are inserted to 
represent summary intraprocedural information about the 
sets of paths between nodes within a procedure, and an 
interprocedural edge is created for each individual variable 
which is passed from a call node to an entry node and from 
an exit node to a return node. These additional edges vary 
with the application. Callahan* s program summary graph 
(with additional summary edges) is applied by Harrold-Soff a 
to determine interprocedural def-use chains, which is a 
bidirectional data flow problem (Harrold and Soffa, Pro- 
ceedings of the IEEE Computer Society 1990 International 
Conference on Computer Languages, 297-306 (1990)). 
Their algorithm has two interprocedural passes, one forward 
and one backward, through the program summary graph. 

There are several problems with the program summary 
graph representation. For the program summary graphs of 
Callahan and Harrold-Soffa, an example can be easily con- 
structed which contains an edge from the entry node to the 
exit node and every call node; and an edge from each return 
node, to the exit node and to every call node, for each 
variable in a procedure. The size of the program summary 
graph representation is large for this example. The size of the 
program summary graph impacts both space and time effi- 
ciency, as an algorithm based on the program summary 
graph must traverse it In the uses of the program summary 
graph, the mechanisms for representing the call stack (prop- 
erly matching calls and returns) and handling recursion vary. 
In Callahan, return edges are ignored, making it impossible 
to incorrecdy match calls and returns; but only unidirec- 
tional problems permit ignoring return (or call) edges. In 
Harrold-Soffa, a bidirectional problem is solved by handling 
call and return edges in separate passes. Other types of 
flow-sensitive problems call for still other techniques. How- 
ever, the prior art discloses no genera) approach. This 
suggests that the prior art program summary graph tech- 
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niques have limited applicability, and therefore do not 
provide a basis for a general solution to interprocedural 
bidirectional problems. 

The prior art known to the inventors discloses no general 
method for solving interprocedural bidirectional data flow 
problems. Therefore, the prior art requires development of a 
particular method for each different interprocedural bidirec- 
tional data flow problem. 

Landi-Ryder (SJGPIAN '92 Conference on Programming 
Language Design and Implementation, 235-248 (June 
1992)) employ the interprocedural control flow graph 
(ICFG) in an algorithm which determines interprocedural 
aliases in programming languages that include general 
pointers (an interprocedural bidirectional data flow prob- 
lem). 

The ICFG contains both inter- and intraprocedural edges, 
which is a disadvantage with respect to its potential use as 
the basis for a general method for solving interprocedural 
bidirectional problems. An interprocedural edge, represent- 
ing a transfer of control between one procedure and another, 
generates bindings between variables (see the description of 
procedural interaction in the preceding background section). 
This information must be incorporated into the data flow 
framework for a particular problem. The intraprocedural 
edges (or nodes) do not create new bindings, but perform 
actions which must be captured in the transfer functions for 
the data flow framework. There is a distinction, then, 
between the kinds of functions generated for the two kinds 
of edges, making it difficult to map an ICFG-based descrip- 
tion into the general definition of data flow frameworks 
given in the preceding background section. 

Another disadvantage to the ICFG representation is that it 
is not compatible with a summary form representation of 
intraprocedural information. A summary representation of a 
procedure does not contain its whole control flow graph, but 
only those nodes which are needed for the interprocedural 
computation (such as entry, call site, and exit nodes). When 
visiting a routine during the traversal of the ICFG, it is 
necessary to visit the individual nodes of its control flow 40 
graph and to propagate their individual transfer functions. 
This generates a less efficient solution than with summary 
information and disallows a flow-insensitive representation. 

Another disadvantage to the ICFG representation is that 
the size of the ICFG increases with the size of the program. 
For a large program, it may be inefficient or impossible to 
store the entire ICFG in memory. Although memory require- 
ments could be lessened by decomposing the ICFG into 
partial representations, algorithms based on the ICFG would 
then have to be revised at some increased cost. 
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OBJECTS OF THE INVENTION 

An objective of this invention is a general system and 
method for solving interprocedural bidirectional data flow 
problems in computer software program analysis. 

Another objective of this invention is an improved system 
and method for interprocedural alias analysis of computer 
software programs that have pointers. 



SUMMARY OF THE INVENTION 

The present invention is a method and apparatus that 
enables a general framework for solving interprocedural 
bidirectional data flow problems. 
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The method is based on the Program Call Graph (PCG) 
representation of a program. The use of the PCG for solving 
interprocedural bidirectional data flow problems is novel. 
The PCG has only interprocedural edges, allowing a dis- 
tinctly separate representation of intraprocedural transfer 
functions from interprocedural transfer functions. This sepa- 
ration of the inter- and intraprocedural frameworks has the 
advantage that the mapping of a particular interprocedural 
bidirectional data flow problem to the general framework for 
monotone data flow problems is straightforward, in contrast 
to the prior art 

The separation of inter- and intraprocedural representa- 
tions has the additional advantage that it allows intraproce- 
dural information to be represented in summary form. For 
example, transfer functions describing the effect of paths 
between pairs of nodes which are relevant to the interpro- 
cedural computation (such as <entry, call site>pairs and<call 
site, exiopairs) can represent the intraprocedural informa- 
tion. When visiting a routine during the traversal of the PCG, 
it is then unnecessary to visit the individual nodes of the 
control flow graph and propagate their individual transfer 
functions. This allows for a more efficient solution. The 
method does not depend upon the particular form of the 
internal representation, which may be either flow-sensitive 
or flow-insensitive. Examples of internal representations 
which could be employed with our method are the control 
flow graph; some sparse version of it, such as the Sparse 
Evaluation Graph (one preferred embodiment disclosed in 
U.S. Pat. No. 5,327,561 filed on Sep. 20, 1991 entitled 
"System and Method for Solving Monotone Information 
Propagation Problems" which is herein incorporated by 
reference in its entirety); or a flow-insensitive summary 
representation. 

With our PCG-based representation of the program, each 
routine has a separate internal representation. An advantage 
to the separate representation of individual routines is the 
efficient use of memory. Since it is unnecessary for the 
internal representation of more than one routine to be in 
memory at once, the memory requirement of the intrapro- 
cedural computation depends on the size of the largest 
routine, compared to the size of the whole program for any 
ICFG-based method. The memory required by the interpro- 
cedural component of our method grows with the size of the 
PCG, which is small compared to the ICFG methods. 

To perform the method, a Program Call Graph (PCG) is 
first constructed. The PCG is a general representation of the 
computer program to be analyzed and contains PCG nodes 
each of which represents a routine in the program. Next an 
internal (intraprocedural) representation is constructed for 
each node of the PCG. The internal representation may (or 
may not) represent the procedure's control flow information. 

Once the PCG and intraprocedural representation arc 
constructed, initial interprocedural values are associated 
with appropriate nodes in the PCG. An intraprocedural 
propagation step is performed that develops a new set of 
interim solution values within the intraprocedural represen- 
tations. In one preferred embodiment of this step, procedures 
are processed one at a time, allowing an efficient use of 
memory. Some of these new interim solution values are then 
interprocedurally propagated by an interprocedural tra- 
versal. 

The traversal comprises a visit to each node of the PCG, 
and proceeds in topological order. When a PCG node is 
visited, the new interim information is propagated in a 
forward and backward direction to other PCG nodes as 
determined by the structure (edges) of the PCG, Each node 
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is visited until the traversal is complete, i.e., when all PCG 
nodes have been visited. Note that the new interim infor- 
mation is propagated in a forward and backward direction in 
one pass of the traversal. 

A completed traversal generates a new set of interim 5 
interprocedural values. If the new set of values differs 
anywhere from the set of interim interprocedural values of 
the prior traversal, another iteration begins at the step of 
intraprocedural propagation. This iteration includes another 
interprocedural traversal of the PCG. Alternatively, if the 10 
two interprocedural value sets are the same, the interproce- 
dural solution has converged and the process ends. This use 
of the PCG for solving interprocedural bidirectional data 
flow problems is novel. 

This general method can be used to determine alias 15 
relationships in computer programs that have pointers. It can 
also be used to perform constant propagation across proce- 
dure calls. 



BRIEF DESCRIPTION OF THE DRAWINGS 
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FIG. 1 shows a prior art example of a flow graph. 

FIG. 2 shows a prior art example of a transfer function. 

FIG. 3 shows a prior art example of a program call graph. 25 

FIG. 4 is a block diagram of a preferred hardware 
embodiment with a compiler practicing the present inven- 
tion. 

FIG. 5 is a flow chart showing the steps of the present 
invention. 30 

FIG. 6 is a block diagram showing the flow of information 
for the present invention and relating the information to the 
phases of a compiler. 

FIG. 7 is a flow graph showing the steps of the present 
invention for computing interprocedural alias information. 

FIG. 8 is a program example which is used to illustrate the 
algorithm for determining interprocedural alias information 
in the presence of pointers. 

FIG. 9 is a program example which is used to illustrate the 40 
matching of call and return interprocedural alias informa- 
tion. 
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FIG. 4 is a block diagram showing a computer system ICO 
on which a preferred embodiment of the present invention 
operates. The preferred embodiment includes one or more 
application programs 102. One type of application program 50 
102 is a compiler 105 which includes an optimizer 105. The 
compiler 105 and optimizer 106 are configured to transform 
a source (like an application program 102) program into 
optimized executable code. More generally, the source pro- 
gram is transformed to an optimized form and then into 55 
executable code. (A more detailed description of basic 
concepts or compilers is 1 found in.Aho et al. t Compilers: 
Principles, Techniques, and Tools by Addison- Wesley 
(1986) which is hereby incorporated by reference in its 
entirety.) 60 

The compiler 105 and optimizer 106 operate on a com- 
puter platform 104 that includes a hardware unit 112. The 
hardware unit 112 includes one or more central processing 
units (CPU) 116, a random access memory (RAM) 114, and 
an input/output interface i 18. Micro- instruction code 110, 65 
for instance a reduced instruction set, may also be included 
on the platform 104. Various peripheral components may be 



connected to the computer platform 104 including a terminal 
126, a data storage device 130, and a printing device 134. An 
operating system 108 coordinates the operation of the vari- 
ous components of the computer system 100. An example of 
computer system 100 like this is the IBM RISC System/ 
6000 (RISC System/6000 is a trademark of the IBM Cor- 
poration.) It is readily understood that those skilled in the 
computer arts will be familiar with many equivalent com- 
puter systems 100. 

FIG. 5 is a flow chart showing the steps of the present 
invention method. FIG. 6 shows the flow of information 
between the modules which embody the method for bidi- 
rectional data flow analysis, and the modules which embody 
the context for the method. In the preferred embodiments, 
the method is executed as part, or a phase 627, of more than 
one phase (107, 625-628) of the compiler optimizer pro- 
gram 106 (FIG. 4). Other optimizer 106 phases (626 and 
628), used to optimize a given application program 102, may 
precede and follow the execution (running) of the present 
method. 

Interprocedural data flow information is determined and 
analyzed in the method by a novel use of the Program Call 
Graph (PCG). Using this method, the general class of 
interprocedural bidirectional data flow problems can be 
solved in an efficient manner. The method 500 in FIG. 5 
starts by building or constructing 510 a PCG 610 using 
techniques disclosed in the prior art Also refer to FIGS. 3 
and 6. (However, note that the prior art known to the 
inventors has never disclosed or recognized the advantages 
of using a PCG to solve interprocedural bidirectional data 
flow problems.) 

Typically, the construction of the Program Call Graph 
(PCG) 510 is performed by an "interprocedural collector" 
(107 in FIG. 6)that is located in the computer system 100 
compiler 105 (preferably in the optimizer 106.) The inter- 
procedural collector 107 is a program that traverses the 
program text of each subroutine in an application program 
102 and identifies all the subroutines called in the applica- 
tion program. As a subroutine is first identified, either as a 
routine to be traversed or as a routine that is invoked during 
a traversal, a node in the PCG (call graph) is generated. As 
a subroutine called by a calling routine is identified, an edge 
is added to the PCG from the calling routine (node) to the 
called routine (node). 

The PCG construction 510 identifies the application pro- 
gram 102 routines (nodes) that call and are called in the 
program and their respective call sites (edges). 

Once this set of application program 102 routines has 
been identified, an intraprocedural representation (i.e. inter- 
nal representation) of each routine is constructed 520. This 
is performed by a phase 625 of the compiler 105 or opti- 
mizer 106. This compiler phase analyzes each PCG node 
(routine) separately and constructs 520 an internal represen- 
tation 630. The method does not depend upon the particular 
form of the internal representation, and one preferred 
embodiment uses a summary representation in all cases for 
efficiency. 

After initialization 525 of the interprocedural solution 660 
(in general, it would be initialized to TOP), the sequence of 
steps of the method is repeated until the interprocedural 
solution converges, as described below. A data flow evalu- 
ation of the each subroutine is performed, using the inter- 
procedural solution as input for each subroutine 640. This 
evaluation comprises determining and propagating new 
interim interprocedural solutions 530. In this step, proce- 
dures are processed one at a time, allowing an efficient use 
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or memory. These solutions 650 are used as input to the 
determination of the interprocedural solution 660. The inter- 
procedural solution is determined hy traversing the PCG 
580. The traversal comprises a visit to each node of the PCG 
540, and the traversal proceeds in topological order. When j 
a PCG node is visited, the new interim information is 
propagated in a forward and backward direction to other 
PCG nodes as determined by the structure (edges) of the 
PCG 545. Each node is visited until the traversal 580 is 
complete, i.e., when all PCG nodes have been visited 550. 10 
Note that the new interim information is propagated in a 
forward and backward direction in one pass of the traversal. 
If the interprocedural solution is unchanged 560, the method 
terminates 570. Otherwise, the body of the loop is repeated 
562. 15 

FIG. 6 is now further described. The source program is 
input to an optimizing compiler 105. The phases of optimi- 
zation 625-628 include analyses and transformations of the 
program. A particular instance of our method, such as 
analysis of pointer aliases, corresponds to one of these 20 
optimization phases (in the diagram, it is identified as 
optimization phase i 627). The information generated during 
phase i can be used by subsequent optimization phases. The 
flow chart of FIG. 5, described above, demonstrates the 
order of steps for phase i. 25 

The following is a pseudo-code description of our general 
method 500 for deterrnining interprocedural bidirectional 
information. It is assumed that an intraprocedural data flow 
framework is defined for the problem. As described in the 
background section, each node Y of this framework is 30 
associated with a "transfer function, and IN r and OUT r are 
related as described there. In addition, OVT entry and OUT^ 
for each call site node Y, are determined as indicated below. 



S t :. foreach procedure, 

OUT^^TOP 

OUT cxil = TOP 
S z : repeat; 

S 3 : fareach procedure P visited in a topological traversal 
over the PCG; 

S 4 : compute OUT catiy of P using IN y at each call site 

Y which invokes P; 
S 5 : perform intraprocedural analysis of P, 

computing OUT wdl of P; 
if Y is a call site in P 
compute OUT y using 
OUT oli4 of the called procedure; 
else 

compute OUTy using IN y and its transfer function; 
S 6 : until convergence; 
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The pseudo-code description is used to provide a more 
detailed account of the general method 500 for interproce- 
dural bidirectional data flow analysis. It is assumed that the 
PCG 510 and the internal representations of the program's 
routines 520 have already been constructed. In step S lf the 55 
entry and exit nodes of each procedure are initialized to TOP 
525. Steps S 2 through S 6 comprise a loop which is repeated 
until the interprocedural solution (i.e., OUT^,^ and OUT^ 
at each procedure) is unchanged by an iteration of the loop 
560. In the FIG. 5 flow chart, the backwards-directed arrow 60 
for this loop is 562. When the loop converges, the interim 
interprocedural solution becomes the final solution 570. 
Steps S 3 through S 5 comprise a loop 580 in which each node 
in the PCG is visited, in topological order. Steps S 4 and S 3 
comprise a PCG node visit (here Box 530 of FIG. 5 is 65 
performed during the topologically ordered visits, which is 
an optimization). At step S 4 , the OUT interim solution at the 



entry node of P is determined. First the meet over all the 
OUT interim solutions holding at the call sites which invoke 
procedure P is performed. Then the meet of this result with 
the current interim solution for OUT at the entry node is 
performed, to arrive at a new interim solution. In FIG. 5, this 
is the interprocedural forward propagation of Box 545. At 
step S 5 , the intraprocedural analysis of P is performed 530. 
As a result of the analysis, a new interim solution at OUT^ 
of P is determined. For call site nodes, as with other nodes, 
new IN interim solutions are determined from the OUT 
interim solutions at predecessor nodes and new OUT interim 
solutions are determined by applying the transfer function 
associated with the node to its interim IN solution. However, 
here the transfer function depends not on local information 
but on information which holds outside the procedure. Since 
the interprocedural problem is bidirectional, it depends on 
information holding in the called procedure. The transfer 
function For the call site is applied by assigning the interim 
solution holding at the exit node of the called procedure to 
the OUT interim solution at the call site node. Since the 
procedures are visited in topological order, the called pro- 
cedure has not yet been visited during this iteration through 
the PCG, so the interim solution determined for its exit node 
during the previous iteration is used. This is how informa- 
tion is propagated backward in the call graph. This step is the 
interprocedural backward propagation of Box 545 in FIG. 5. 
Note that this occurs during a topological (forward) tra- 
versal: a backward (reverse topological) traversal of the call 
graph is unnecessary. 

For efficiency, the iterative algorithm could be imple- 
mented with a worklist representing the nodes yet to be 
processed. 

An example of an application of our framework is the 
determination of interprocedural aliases in programming 
languages that include pointers, e.g., C, C**, and Fortran 90. 

Interprocedural Alias Analysis 

Out method for determining interprocedural aliases is 
now described. This is an example of our general purpose 
method 500 for deterrnining interprocedural bidirectional 
data flow information. Aliases occur when two or more 
access paths refer to the same storage location. An access 
path is an 1 -value expression which is constructed from 
variables, pointer indirection operators, and field select 
operators. Static aliases occur due to the FORTRAN 
EQUIVALENCE or C union construct and are constant for 
the duration of the program execution. Static alias informa- 
tion is typically determined during the semantic phase of 
compilation, and is not further considered here. Dynamic 
aliases arise during program execution. Program constructs 
such as the FORTRAN reference parameter mechanism and 
pointers induce dynamic aliasing. Two access paths are 
may-aliases at a point p in a program if they refer to the same 
storage location in some execution instances of p. This 
section describes the determination of may-aliases. May- 
aliases are referred to as aliases, whenever the meaning is 
clear from context In tile presence of pointers, the alias 
relations at the exit of a called routine are propagated to the 
return site in the calling routine and those at the call site in 
the calling routine arc propagated to the entry node of the 
called routine. Thus, interprocedural alias analysis in the 
presence of pointers is bidirectional. 

FIG. 7 is a flow chart which illustrates the steps of the 
present invention for computing interprocedural alias infor- 
mation. The application of the general method 500 to this 
problem results in a method 700 which determines interpro- 
cedural alias information by traversing the Program Call 
Graph (PCG). 



04/23/2004, EAST Version: 1.4.1 



5,485,616 



11 



12 



The method 700 in FIG. 7 starts by building or construct- 
ing 710 a PCG 610 using techniques disclosed in the prior 
art. Typically, the construction of the PCG 710 is performed 
by an interprocedural collector" (107 in FIG. 6) that is 
located in the computer system 100 compiler 105 (prefer- 5 
ably in the optimizer 106) which also collects alias infor- 
mation. 

After the set of application program 102 routines has been 
identified, an internal (intraprocedural) representation of 
each routine is constructed 720 which contains the alias 10 
information. The method does not depend upon the particu- 
lar form of the internal representation, and one preferred 
embodiment uses a summary representation in all cases for 
efficiency. 

Alter initialization 725 of the interprocedural solution 660 is 
to the static alias set for each routine, the sequence of steps 
of the method is repeated until the interprocedural alias 
solution converges, as described below. 

As each procedure is visited, alias information within it is 
propagated from the entry node by some intraprocedural 20 
alias analysis method 730. Updated exit information is 
propagated backward in the PCG to the return points of 
invoking procedures, and updated call site information is 
propagated forward in the PCG to the entry point of the 
called procedure 745. Each node is visited until the traversal 25 
780 is complete, i.e. when all PCG nodes have been visited 
750. Note that the new interim alias information is propa- 
gated in a forward and backward direction in one pass of the 
traversal If the interprocedural solution is unchanged 760, 
the method terminates 770. Otherwise the body of the loop 30 
is repeated 762. 

The following pseudo-code describes the method for 
determining interprocedural alias information in the pres- 
ence of pointers. Let A ¥ JN and A r OUT be the set of alias 
relations holding at the entry and exit of node Y, respec- 35 
tively. A r /V and A Y OUT correspond to IN y and OUT y as 



40 



question is clear from context. 
S t : foreach procedure, 

A«"^ OCT =STATIC_ALIASES 



S 2 : repeat; 45 
S 3 : foreach procedure P visited in a topological traversal 
over the PCG; 

S 4 : compute A mtry OUT of P using A r m at each call site node 

Y which invokes P; 
S 3 : perform intraprocedural analysis of P, 50 

computing. A^'o^t. of P; 
if Y is a call site in P compute A r OUT using 
A exU OUT of the called procedure; else 
compute A Y OUT using A Y W and its transfer function; 
S 6 : until convergence; 55 

Using the pseudo-code description, a more detailed 
account of the method 700 for interprocedural bidirectional 
alias analysis is now provided. The steps S t through S 6 
correspond to the same steps in the general method 500 
described above. In step S,. the static aliasing for a proce- 60 
dure is used to initialize its A €ntry our set 725. Steps S 2 
through S 6 comprise a loop 762 which is repeated until the 
interprocedural alias solution (i.e., A^^o^and A CT " ota .at 
each procedure) is unchanged by an iteration of the loop 
760. When the loop converges, the interim interprocedural 65 
solution becomes the final solution 770. Steps S 3 through S 3 
comprise a loop 780 in which each node in the PCG is 



visited, in topological order. Steps S 4 and S 5 comprise a 
PCG node visit. At step &, alias information at the entry 
node of P, A*""^^ is determined by first unioning the 
intraprocedural aliases (i.e^, interim solutions) holding at the 
call sites which invoke procedure P and then unioning the 
resulting set with the current interim solution at the entry 
node of P, to arrive at a new interim solution 745. At step S 5 , 
the intraprocedural analysis of P is performed 730. As a 
result of the analysis, a new interim solution at OUT^ of 
P is determined. Due to pointers, the interprocedural alias 
problem is bidirectional. For a call site node Y, as with the 
general method, A**" ol ^. of the called procedure (the 
interim solution which was determined during the previous 
iteration through the PCG) becomes the new interim solu- 
tion at A wi, OI ^ This is how information is propagated 
backward in the call graph 745. (We introduce an enhance- 
ment to the precision of this backward walk, described in the 
ensuing section.) As with our general method, topological- 
order iterations over the PCG are sufficient 

For efficiency, the iterative algorithm could be imple- 
mented with a worklist representing the nodes yet to be 
processed. 

FIG. 8 is an example program with pointer-induced 
aliases. Statement SO contains a declaration of global vari- 
ables. Procedure P is defined in statements SI through S7. 
Procedure Q is defined in statements S8 through Sll. In the 
following, we denote that variables a and b are aliased by 
<a,b>. The topological traversal of the call graph involves 
visiting P and then Q. A" 1 "*,^ is initially the empty set for 
P. Intraprocedural analysis detects that the alias <*u,a> is 
generated by statement S 4 and holds at the call site S 3 . 
K^our for Q is initially the empty set, so the interim 
solution for OUT at the call site S 5 is assigned the empty set. 
At S 7 , the exit node of P, intraprocedural analysis determines 
that the interim solution is also the empty. Next Q is visited. 
The interim solution at its entry node is determined from the 
interim solution for IN at the call site S 3 , and so is assigned 
{<*u,a>}. Intraprocedural analysis determines that at Si 0 , 
the alias <*u,b> is generated and the alias <*u,a> no longer 
holds. Intraprocedural analysis also determines that at S n , 
the exit node of Q, the interim solution is {<*u,b>}. This 
completes the first traversal of the call graph. Interproce- 
durally relevant interim solutions have changed, so a second 
traversal is required. In the second visit to P, the interim 
solution at OUT for the call site node S 5 becomes {<*u,b>}, 
because this is the interim solution at the exit node for Q. 
Intraprocedural analysis determines that at S 7 , the exit node 
of P, the interim solution is now {<*u,b>}. In the second 
visit to Q, no interim solutions are modified. Since the 
interim solution at the exit node of P is altered by the second 
traversal, a third traversal takes place. No changes occur 
during the third traversal, so the algorithm terminates and 
the current interim solutions comprise the final solution. 

FIG. 9 shows three procedures, SUB1, SUB2, and SUB3, 
and the corresponding PCG. This figure is used to illustrate 
a preferred embodiment of our method for determining 
interprocedural alias information. Alias relations holding at 
the entry node of SUB3 consist of {<p,s>, <*r,X >, <*p, 
*q>}. (It is assumed that no alias relations hold before any 
of the procedures are called.) Of these three alias relations, 
<*p,s> and <*r,X> are propagated along the PCG edge from 
SUB1 to SUB3, and <*p,*q> is propagated along the PCG 
edge from SUB2 to SUB3. The alias relations holding at the 
exit of SUB3 are different from those at the entry node, due 
to the assignment to *p in SUB3, and arc propagated to the 
points in SUB1 and SUB2 immediately following the invo- 
cations of SUB3. Our interprocedural bidirectional analysis 
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correctly determines <*p,s>, <*r,X>, <**p *r 22 , <**p,X>, 
<*s *r>, <*s,X> as the alias relations holding immediately 
after the call to SUB3 in SUB1, and <*p,*q>. <**p *r>, 
<**q,*r> as the alias relations holding immediately after the 
call to SUB3 in SUB2. 5 

Although a called procedure can affect the aliases holding 
on return from the call sites which invoke it, k^'our of a 
procedure does not uniformly affect all the procedures which 
call it Rather, the aliases holding on return from a call site 



C a are affected only by a subset of A 



. of the called 10 



procedure. This subset includes only those aliases induced 
by aliases holding just prior to C a or generated in the called 
procedure independently of the aliases holding at the invok- 
ing call sites. 

Our method correctly identities, for each alias relation of 15 
A^'oim me call s * tes whose aliases have induced the alias 
relation. The transfer functions and the representation of the 
alias relation are extended to accomplish this. 

Given this disclosure, a person skilled in the computer arts 
could develop alternative equivalent embodiments which 20 
are within the contemplation and scope of the present 
invention. 

We claim: 

1. In a computer processor executing a computer com- 
piler, a computer implemented method performed by the 25 
computer compiler for deternuning the Maximum Fixed 
Point interprocedural solution of an interprocedural bidirec- 
tional data flow problem for a computer program application 
comprising the steps of: 

a. constructing a Program Call Graph of the computer 30 
program application, the Program Call Graph having a 
plurality of Program Call Graph nodes and edges, each 
Program Call Graph node representing a routine in the 
computer program application and each Program Call 
Graph edge connecting two Program Call Graph nodes, 35 
a calling Program Call Graph node and a called Pro- 
gram Call Graph node, the Program Call Graph edge 
having a direction from the calling Program Call Graph 
node to the called Program Call Graph node; 

b. constructing an intraprocedural representation for each 40 
Program Call Graph node, the intraprocedural repre- 
sentation being a flow graph with one or more Intra- 
procedural Flow Graph nodes, each Intraprocedural 
Flow Graph node representing a program statement that 

is able to change a data flow solution, each Intrapro- 45 
cedural Flow Graph having one entry node, one exit 
node, a call site node for each of zero or more call sites 
in the routine, and a return point associated with each 
call site; 

c. in the flow graph in each Program Call Graph node, 
initializing an entry node value for the entry node and 
an exit node value for the exit node, the entry node 
value and the exit node value being interprocedural 
values that represent an interim fixed point interproce- 55 
dural solution for the routine represented by the Pro- 
gram Call Graph node; 

d. for each Program Call Graph node in the Program Call 
Graph, determining an interim intraprocedural solution 
by means of a data flow analysis method, the interim go 
intraprocedural solution including a new exit node 
value at the exit node and a new call site value at each 

of the call sites, and substituting the new exit node 
value for the exit node value and the new call site 
values for the respective call site values; 65 

e. determining a new interim fixed point interprocedural 
solution for each of the Program Call Graph nodes in 
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topological order in the Program Call Graph by inter- 
procedurally propagating the new exit node value from 
the exit node to the call site return point of each of the 
calling Program Call Graph nodes calling the Program 
Call Graph node interprocedurally propagating the new 
call site values from the Program Call Graph node call 
sites to each of the entry nodes of the called program 
Call Graph nodes called by the Program Call Graph 
node; and 

f. if any interprocedural values have been modified by the 
iteration performed by step e, then going to step d; 
otherwise selecting the current interprocedural values 
as the Maximum Fixed Point interprocedural solution. 

2. A method for determining the Maximum Fixed Point 
solution of an interprocedural bidirectional data flow prob- 
lem for a computer program as in claim 1 above where the 
intraprocedural representation is in summary form. 

3. A method for determining the Maximum Fixed Point 
solution of an interprocedural bidirectional data Mow prob- 
lem for a computer program as in claim 1 above where the 
intraprocedural representation is flow-sensitive because 
intraprocedural control flow information is included in 
determining the interim intraprocedural solution. 

4. A method for determining the Maximum Fixed Point 
solution of an interprocedural bidirectional data flow prob- 
lem for a computer program as in claim i above where the 
intraprocedural representation is flow-insensitive because 
intraprocedural control flow information is not included in 
determining the interim intraprocedural solution. 

5. A method for determining the Maximum Fixed Point 
solution of an interprocedural bidirectional data flow prob- 
lem for a computer program as in claim 1 above where the 
intraprocedural representation is a Sparse Evaluation Graph, 
the Sparse Evaluation Graph being a Sparse representation 
of forward or backward propagation of data flow values. 

6. A method for determining the Maximum Fixed Point 
solution of an interprocedural bidirectional data flow prob- 
lem for a computer program as in claim 1 where each entry 
node value or each interim fixed point interprocedural 
solution is identified with an Inducing Program Call Graph 
node, the Inducing Program Call Graph node having the call 
site inducing the new entry node values, and the interpro- 
cedural propagation ..propagating zero or more of the new 
exit node values only to the respective call site return point 
of the Inducing Program Call Graph node. 

7. In a computer processor executing a computer com- 
piler, a computer implemented method performed by the 
computer compiler for determining the Maximum Fixed 
Point interprocedural solution of one or more aliases 
induced by pointers, for programming languages that 
include general pointers, for a computer application program 
comprising the steps of: 

a. constructing a Program Call Graph of the computer 
application program, the Program Call Graph having a 
plurality of Program Call Graph nodes and edges, each 
Program Call Graph node representing a routine in the 
computer application program and each Program Call 
Graph edge connecting two Program Call Graph nodes, 
a calling Program Call Graph node and a called Pro- 
gram Call Graph node, the Program Call Graph edge 
having a direction from the calling Program Call Graph 
node to the called Program Call Graph node; 

b. constructing an intraprocedural representation for each 
Program Call Graph node, the intraprocedural repre- 
sentation being a flow graph with one or more Intra- 
procedural Flow Graph nodes, each Intraprocedural 
Flow Graph node representing a program statement that 
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is able to change an alias solution, each Intraprocedural 
Flow Graph having one entry node, one exit node, a call 
site node for each of zero or more call sites in the 
routine, and a return point associated with each call 
site; 5 

c. in the flow graph in each Program Call Graph node, 
initializing an entry node alias value for the entry node 
and an exit node alias value for the exit node, the entry 
node alias value and the exit node alias value being 
interprocedural values that represent an interim fixed 10 
point interprocedural alias solution for the routine 
represented by the Program Call Graph node; 

d. for each Program Call Graph node in the Program Call 
Graph, determining an intraprocedural interim alias 
solution by means of an alias analysis method, the 15 
interim intraprocedural alias solution including a new 
exit node alias value at the exit node and a new call site 
alias value at each of the call sites, and substituting the 
new exit node alias value for the exit node alias value 
and the new call site alias values for the respective call 
site alias values; 

e. determining a new interim fixed point interprocedural 
solution for each of the Program Call Graph nodes in 
topological order in the Program Call Graph by inter- ^ 
procedurally propagating the new exit node alias value 
from the exit node to the call site return point of each 
of the calling Program Graph nodes calling the Pro- 
gram Call Graph node and interproceduraUy propagat- 
ing the new call site alias values from the Program Call 3Q 
Graph node call sites to each of the entry nodes of the 
called Program Call Graph nodes called by the Program 
Call Graph node; and 

f. if any interprocedural values have been modified by the 
iteration performed by step e, then going to step d; 35 
otherwise selecting the current interprocedural values 

as the Maximum Fixed Point interprocedural solutioa 

8. A method for determining the Maximum Fixed Point 
solution of an interprocedural aliasing problem for a com- 
puter program as in claim 7 where each entry node alias 40 
value of each interim fixed point interprocedural alias solu- 
tion is identified with an Inducing Program Call Graph node, 
the Inducing Program Call Graph node having the call site 
inducing the new entry node alias values, and the interpro- 
cedural propagation propagating zero or more of the new 45 
exit node alias values only to the respective call site return 
point or the Inducing Program Call Graph node. 

9. A computer system having a platform with random 
access memory, a central processing unit, an input/output 
interface and an operating system, also having one or more 50 
input/output means, one or more application programs, and 

a computer processor executing a computer compiler, a 
computer implemented method for determining the Maxi- 
mum Fixed Point solution of an interprocedural bidirectional 



data flow problem for a computer application program by 
performing the steps of: 

a. constructing a Program Call Graph of the computer 
program application, the Program Call Graph having a 
plurality of Program Call Graph nodes and edges, each 
Program Call Graph node representing a routine in the 
computer program application and each Program Call 
Graph edge connecting two Program Call Graph nodes, 
a calling Program Call Graph node and a called Pro- 
gram Call Graph node, the Program Call Graph edge 
having a direction from the calling Program Call Graph 
node to the called Program Call Graph node; 

b. constructing an intraprocedural representation for each 
Program Call Graph node, the intraprocedural repre- 
sentation being a flow graph with one or more Intra- 
procedural Flow Graph nodes, each Intraprocedural 
Flow Graph node representing a program statement that 
is able to change a data flow solution, each Intrapro- 
cedural Flow Graph having one entry node, one exit 
node, a call site node for each of zero or more call sites 
in the routine, and a return point associated with each 
call site; 

c. in the flow graph in each Program Call Graph node, 
initializing an entry node value for the entry node and 
an exit node value for the exit node, the entry node 
value and the exit node value being interprocedural 
values that represent an interim fixed point interproce- 
dural solution for the routine represented by the Pro- 
gram Call Graph node; 

d\ for each Program Call Graph node in tile Program Call 
Graph, determining an interim intraprocedural solution 
by means of a data flow analysis method, the interim 
intraprocedural solution including a new exit node 
value at the exit node and a new call site value at each 
of the call sites, and substituting the new exit node 
value for the exit node value and the new call site 
values for the respective call site values; 

e. determining a new interim fixed point interprocedural 
solution for each of the Program Call Graph nodes in 
topological order in the Program Call Graph, by inter- 
proceduraUy propagating the new exit node value from 
the exit node to the call site return point of each of the 
calling Program Call Graph nodes calling the Program 
Call Graph node and interprocedurally propagating the 
new call site values from the Program Call Graph node 
call sites to each of the entry nodes of the called 
Program Call Graph nodes called by the Program Call 
Graph node; and 

f. if any interprocedural values have been modified by the 
iteration performed by step e, then going to step d; 
otherwise selecting the current interprocedural values 
as the Maximum Fixed Point interprocedural solution. 
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